🏁 Script executed:

#!/bin/bash
# Validate the workflow YAML and confirm workflow_call.inputs is populated.
python - <<'PY'
import sys, yaml
with open('.github/workflows/build-desktop.yml') as f:
    try:
        doc = yaml.safe_load(f)
    except yaml.YAMLError as e:
        print("YAML parse error:", e); sys.exit(1)
wc = (doc.get('on') or doc.get(True) or {}).get('workflow_call') or {}
print("workflow_call.inputs keys:", list((wc.get('inputs') or {}).keys()))
print("top-level permissions:", doc.get('permissions'))
PY

Repository: tinyhumansai/openhuman

Length of output: 183

🏁 Script executed:

# First, let's view the current build-desktop.yml around lines 14-25 to see exact indentation
sed -n '14,25p' .github/workflows/build-desktop.yml | cat -A

Repository: tinyhumansai/openhuman

Length of output: 321

🏁 Script executed:

# Now test the corrected structure by creating a test YAML and validating it
python - <<'PY'
import sys, yaml

# Read current file
with open('.github/workflows/build-desktop.yml', 'r') as f:
    content = f.read()
    
# Show what we have at lines 14-25
lines = content.split('\n')
print("Current lines 14-25:")
for i in range(13, min(25, len(lines))):
    print(f"{i+1:3d}: {repr(lines[i])}")

print("\n" + "="*60)
print("Attempting to parse current file:")
try:
    doc = yaml.safe_load(content)
    print("ERROR: File parsed successfully (unexpected!)")
except yaml.YAMLError as e:
    print(f"✓ Parse error confirmed: {e}")
PY

Repository: tinyhumansai/openhuman

Length of output: 648

🏁 Script executed:

# Find the line containing "inputs:" to understand the structure
grep -n "inputs:" .github/workflows/build-desktop.yml | head -5

Repository: tinyhumansai/openhuman

Length of output: 81

🏁 Script executed:

# Get broader context: lines 1-30
sed -n '1,30p' .github/workflows/build-desktop.yml | cat -n

Repository: tinyhumansai/openhuman

Length of output: 1391

🏁 Script executed:

# Find where the on: block ends (jobs: keyword marks next top-level section)
grep -n "^jobs:" .github/workflows/build-desktop.yml

Repository: tinyhumansai/openhuman

Length of output: 76

🏁 Script executed:

# Get lines around the end of the on: block (inputs section)
sed -n '90,105p' .github/workflows/build-desktop.yml | cat -n

Repository: tinyhumansai/openhuman

Length of output: 843

🏁 Script executed:

# Test the proposed fix by creating corrected YAML
python - <<'PY'
import yaml

# Create the corrected structure
corrected_yaml = """
on:
  workflow_call:
    inputs:
      build_ref:
        description: Git ref to check out for the build (tag or SHA).
        type: string
        required: true
permissions:
  contents: read
  actions: write
jobs:
  build:
    runs-on: ubuntu-latest
"""

print("Testing corrected YAML structure:")
try:
    doc = yaml.safe_load(corrected_yaml)
    wc = (doc.get('on') or {}).get('workflow_call') or {}
    print(f"✓ YAML parses successfully")
    print(f"  workflow_call.inputs keys: {list((wc.get('inputs') or {}).keys())}")
    print(f"  top-level permissions: {doc.get('permissions')}")
except yaml.YAMLError as e:
    print(f"✗ Parse error: {e}")
PY

Repository: tinyhumansai/openhuman

Length of output: 225

🏁 Script executed:

# Now check line 587 to understand what permission is needed for gh release upload
sed -n '580,595p' .github/workflows/build-desktop.yml | cat -n

Repository: tinyhumansai/openhuman

Length of output: 811

🏁 Script executed:

# Verify the permission scope: check if there are other uses of contents: write needed
grep -n "gh release\|contents: write\|actions: write" .github/workflows/build-desktop.yml

Repository: tinyhumansai/openhuman

Length of output: 180

🏁 Script executed:

# Check the current permission block in context (lines 13-20)
sed -n '13,20p' .github/workflows/build-desktop.yml | cat -n

Repository: tinyhumansai/openhuman

Length of output: 250

🏁 Script executed:

# Test what the corrected permissions should be
python - <<'PY'
import yaml

# Test with correct permissions scope
corrected_yaml_with_full_inputs = """
on:
  workflow_call:
    inputs:
      build_ref:
        description: Git ref
        type: string
        required: true
      with_updater:
        description: desc
        type: boolean
        default: true
permissions:
  contents: write
jobs:
  build:
    runs-on: ubuntu-latest
"""

print("Testing corrected YAML with contents: write (for gh release upload):")
try:
    doc = yaml.safe_load(corrected_yaml_with_full_inputs)
    wc = (doc.get('on') or {}).get('workflow_call') or {}
    inputs = list((wc.get('inputs') or {}).keys())
    perms = doc.get('permissions')
    print(f"✓ YAML parses successfully")
    print(f"  workflow_call.inputs keys: {inputs}")
    print(f"  top-level permissions: {perms}")
    if 'build_ref' in inputs and 'with_updater' in inputs:
        print(f"✓ All inputs properly nested under workflow_call")
except yaml.YAMLError as e:
    print(f"✗ Parse error: {e}")
PY

Repository: tinyhumansai/openhuman

Length of output: 241

🏁 Script executed:

# Check what the actual fix should look like - find exact end of inputs block
sed -n '95,102p' .github/workflows/build-desktop.yml | cat -A

Repository: tinyhumansai/openhuman

Length of output: 402

🏁 Script executed:

# Verify where inputs block ends to understand complete fix scope
sed -n '19,100p' .github/workflows/build-desktop.yml | grep -n "^ " | tail -1

Repository: tinyhumansai/openhuman

Length of output: 91

🏁 Script executed:

# Check what permissions release upload actually requires
python - <<'PY'
# According to GitHub Actions documentation:
# - actions/checkout@v4: needs contents:read
# - actions/cache@v5: does NOT require actions:write (uses its own service token)
# - actions/upload-artifact@v5: does NOT require actions:write (uses artifact service, not GITHUB_TOKEN for uploads)
# - gh release upload: needs contents:write (releases are part of repository contents)

# The workflow uses "gh release upload" at line 587, so:
print("Permission requirements for this workflow:")
print("- contents:read  (for actions/checkout)")
print("- contents:write (for gh release upload at line 587)")
print("- actions:write  (NOT needed for cache, checkout, or upload-artifact)")
print("\nConclusion: permissions should be 'contents: write' (or 'contents: read' if release upload is disabled)")
print("The current 'contents: read + actions: write' is WRONG for two reasons:")
print("  1. actions:write is unnecessary")
print("  2. contents:read is insufficient for gh release upload (needs write)")
PY

Repository: tinyhumansai/openhuman

Length of output: 554

🏁 Script executed:

# Final test: create a complete valid YAML structure matching the file
python - <<'PY'
import yaml

# Simulate the corrected structure with proper indentation
corrected = """---
name: Build Desktop (reusable)
on:
  workflow_call:
    inputs:
      build_ref:
        description: Git ref to check out for the build (tag or SHA).
        type: string
        required: true
      tag:
        description: Tag name
        type: string
        required: true
      with_updater:
        description: When true, set WITH_UPDATER=true
        type: boolean
        default: true
permissions:
  contents: write
jobs:
  build:
    runs-on: ubuntu-latest
"""

print("Testing corrected structure (with contents:write):")
try:
    doc = yaml.safe_load(corrected)
    on_block = doc.get('on') or {}
    wc = on_block.get('workflow_call') or {}
    inputs = wc.get('inputs') or {}
    perms = doc.get('permissions') or {}
    
    print(f"✓ YAML parses successfully")
    print(f"  on.workflow_call.inputs: {list(inputs.keys())}")
    print(f"  permissions: {perms}")
    print(f"  jobs: {list(doc.get('jobs', {}).keys())}")
except yaml.YAMLError as e:
    print(f"✗ Parse error: {e}")
PY

Repository: tinyhumansai/openhuman

Length of output: 229

🏁 Script executed:

# Confirm the end of the on: block and structure
sed -n '14,100p' .github/workflows/build-desktop.yml | grep -E "^(on:|  workflow_call:|permissions:|jobs:)" | head -5

Repository: tinyhumansai/openhuman

Length of output: 106

🌐 Web query:

What GITHUB_TOKEN permissions are required for actions/upload-artifact v5, actions/cache v5, and gh release upload in 2026?

💡 Result:

actions/upload-artifact@v5: contents: read (works even with empty permissions in private repos, but contents: read explicitly for safety) [1]. Official docs do not specify beyond general repo access, and artifact upload uses a special token but GITHUB_TOKEN needs contents: read for checkout/context [2][3]. actions/cache@v5: actions: write (for saving/restoring caches, as cache is managed under Actions API) [4][3]. Docs confirm no explicit permissions listed, but related tools require actions: read/write [5]. gh release upload: contents: write (required for creating/updating releases and uploading assets via REST API /releases endpoint) [6][7][8][9]. Uses GH_TOKEN which maps to contents permission for repo write operations including releases [10].

Citations:

• 1: Add details on authentication / permissions used during upload actions/upload-artifact#197
• 2: https://docs.github.com/en/rest/actions/artifacts?apiVersion=2026-03-10
• 3: https://github.com/actions/toolkit/blob/main/packages/artifact/README.md
• 4: Document that actions: read/write permissions are required to use gh-actions-cache in gh actions CI actions/gh-actions-cache#85
• 5: https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching
• 6: https://stackoverflow.com/questions/67389957/what-permissions-does-github-token-require-for-releases-from-a-github-action
• 7: https://docs.github.com/en/rest/releases/releases?apiVersion=2026-03-10
• 8: https://github.com/elgohr/Github-Release-Action
• 9: https://github.com/step-security/action-gh-release
• 10: https://pdsinterop.org/docs/development/github-actions/github-actions.permissions

🌐 Web query:

Does actions/cache@v5 use GITHUB_TOKEN or a separate cache service token? GitHub Actions permissions

💡 Result:

actions/cache@v5 uses the GITHUB_TOKEN (via ${{ github.token }} context) to access GitHub's built-in cache service. It does not require a separate cache service token. The action internally calls GitHub's REST API endpoints for Actions cache (e.g., list, get, create, update caches), which require the GITHUB_TOKEN to have actions:read (for restore) and actions:write (for save) permissions [1][2][3][4][5][6]. By default, GITHUB_TOKEN has these permissions unless restricted in the workflow [3][7]. No external cache service or additional token is needed or mentioned in official docs or the action's README [8][9][2][10][11]. For explicit cache management (e.g., delete via gh cache), actions:write must be granted [1][4][7].

Citations:

• 1: Document that actions: read/write permissions are required to use gh-actions-cache in gh actions CI actions/gh-actions-cache#85
• 2: https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching
• 3: https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
• 4: https://github.com/actions/cache/pull/1123](https:/togithub.com/actions/cache/pull/1123)
• 5: https://docs.github.com/en/rest/actions/cache?apiVersion=2026-03-10
• 6: https://docs.github.com/rest/actions/cache
• 7: https://docs.github.com/en/actions/how-tos/managing-workflow-runs-and-deployments/managing-workflow-runs/manage-caches
• 8: https://github.com/actions/cache/blob/v5/README.md
• 9: https://github.com/actions/cache
• 10: https://github.com/actions/cache/blob/main/README.md
• 11: http://github.com/actions/cache

🌐 Web query:

GitHub Actions cache token mechanism in 2026 - GITHUB_TOKEN vs runner cache service

💡 Result:

In 2026, GitHub Actions caching uses an internal “Actions cache service” authentication token (ACTIONS_RUNTIME_TOKEN / bearer token), not the same credential that you normally use as GITHUB_TOKEN for GitHub API calls. 1) What GITHUB_TOKEN is (and is for) - GITHUB_TOKEN is the automatically generated token in a workflow job; it can be used for authenticated GitHub API calls and its permissions are controlled via the workflow’s permissions settings. It expires after the job completes and is scoped to the repository that contains the workflow.[1][2] 2) What the cache service token is (and is for) - The cache action (actions/cache) talks to GitHub’s cache backend service over an internal HTTP API. In the actions/toolkit cache HTTP client used by actions/cache, the client reads a token from the environment variable ACTIONS_RUNTIME_TOKEN and sends it as a Bearer credential in requests to the cache service.[3] - The Docker BuildKit “gha” cache backend docs likewise describe cache v2 inputs as coming from ACTIONS_RESULTS_URL and ACTIONS_RUNTIME_TOKEN, describing token “see authentication”.[4][5] 3) How the two differ in practice (GITHUB_TOKEN vs cache token) - GITHUB_TOKEN: intended for GitHub API authentication and is the token you reference as secrets.GITHUB_TOKEN / github.token.[2] - Cache service token (ACTIONS_RUNTIME_TOKEN): intended for calling the cache/artifacts/runtime service endpoints that actions/cache uses. It’s provided by the runner for workflow/action execution contexts, and it is the token wired into the cache HTTP client (Bearer) to access the cache service endpoints.[3][6] 4) Does actions/cache fall back to GITHUB_TOKEN? - The published toolkit cache client code shown above specifically uses ACTIONS_RUNTIME_TOKEN as the token it loads for cache service communication.[3] - I did not find an authoritative 2026 doc explicitly stating “ACTIONS_RUNTIME_TOKEN == GITHUB_TOKEN”. What is clearly documented is that cache actions depend on their runtime environment variables for cache service access, while GITHUB_TOKEN is for GitHub API authentication.[3][2][5] 5) Security boundary note (why GitHub doesn’t want you storing secrets in caches) - GitHub explicitly recommends not storing sensitive information (including access tokens/credentials) in cached files because cache contents can be accessed via pull requests from forks / readers.[7] Bottom line - Use GITHUB_TOKEN for GitHub API calls. - For GitHub Actions cache upload/download via actions/cache (and cache service v2 clients), the authentication mechanism is the bearer token provided to the runtime as ACTIONS_RUNTIME_TOKEN (with cache service URLs like ACTIONS_RESULTS_URL), not GITHUB_TOKEN by itself.[3][4][2]

Citations:

• 1: https://docs.github.com/en/actions/concepts/security/compromised-runners
• 2: https://docs.github.com/actions/reference/authentication-in-a-workflow
• 3: https://github.com/actions/toolkit/blob/500d0b42fee2552ae9eeb5933091fe2fbf14e72d/packages/cache/src/internal/cacheHttpClient.ts
• 4: https://docs.docker.com/build/cache/backends/gha
• 5: https://docs.docker.com/build/ci/github-actions/cache
• 6: Add ACTIONS_RUNTIME_TOKEN and runtime env vars to ScriptHandler actions/runner#4325
• 7: https://docs.github.com/actions/advanced-guides/caching-dependencies-to-speed-up-workflows

🌐 Web query:

Official GitHub documentation actions/cache@v5 GITHUB_TOKEN permissions requirements

💡 Result:

Official GitHub documentation / behavior: actions/cache@v5 doesn’t require you to pass GITHUB_TOKEN explicitly. GitHub Actions provides a GITHUB_TOKEN automatically to each job, and workflow/job permissions: controls what that token can do for the job [1][2]. What permissions: you need for actions/cache@v5: - To allow the GITHUB_TOKEN to create/save or manage GitHub Actions caches used by actions/cache, you generally need the actions scope to be writable: set permissions: actions: write (commonly alongside contents: read if you also check out code). - This is supported by GitHub’s mechanism for configuring GITHUB_TOKEN permissions via permissions: at the workflow/job level [2][3]. - Cache-related guidance indicates actions: write is needed for cache management operations that hit the Actions cache REST API (e.g., delete or other operations beyond restore). For example, a documented fix states permissions: actions: write as the needed setting [4]. - GitHub Actions “actions cache” operations (like delete) also reference actions:write as the required permission in practice [5]. Example (least privilege for typical cache usage + checkout): - Job-level permissions: - contents: read - actions: write Notes / gotchas: - GITHUB_TOKEN is a GitHub App installation access token whose permissions are limited; you can control those permissions with permissions: [1][6]. - Forked pull requests are treated specially and may receive reduced GITHUB_TOKEN permissions (often read-only), which can restrict cache write/save behavior depending on the trigger/context [6][7].

Citations:

• 1: https://docs.github.com/en/actions/concepts/security/github_token
• 2: https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
• 3: https://docs.github.com/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token
• 4: Document that actions: read/write permissions are required to use gh-actions-cache in gh actions CI actions/gh-actions-cache#85
• 5: https://github.com/actions/cache/pull/1123](https:/togithub.com/actions/cache/pull/1123)
• 6: https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/
• 7: https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching

🏁 Script executed:

# Check if the file exists and read the relevant sections
if [ -f ".github/workflows/build-desktop.yml" ]; then
  echo "=== Permissions block (lines 16-18) ==="
  sed -n '15,20p' .github/workflows/build-desktop.yml
  
  echo -e "\n=== gh release upload at line 587 ==="
  sed -n '585,590p' .github/workflows/build-desktop.yml
  
  echo -e "\n=== macOS re-upload script at line 657 ==="
  sed -n '655,660p' .github/workflows/build-desktop.yml
  
  echo -e "\n=== All uses of gh release or release upload ==="
  grep -n "gh release\|release.*upload" .github/workflows/build-desktop.yml || echo "No matches found"
else
  echo "File not found"
fi

Repository: tinyhumansai/openhuman

Length of output: 1621

🏁 Script executed:

# Also check if actions/cache and actions/upload-artifact are used
echo "=== Actions used in workflow ==="
grep -n "uses.*actions/cache\|uses.*actions/upload-artifact" .github/workflows/build-desktop.yml || echo "Not found"

Repository: tinyhumansai/openhuman

Length of output: 364

 permissions:
-  contents: read
-  actions: write
+  contents: write

If you prefer least-privilege granularity, scope contents: write only to the release upload steps via step-level permissions: and leave the workflow default at contents: read.

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.